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Abstract 

The  history  of  the  application  of  formal  methods 
to  cryptographic  protocol  analysis  spans  nearly  twenty 
years,  and  recently  has  been  showing  signs  of  new  ma¬ 
turity  and  consolidation.  A  number  of  specialized  tools 
have  been  developed,  and  others  have  effectively  demon¬ 
strated  that  existing  general-purpose  tools  can  also  be 
applied  to  these  problems  with  good  results.  However, 
with  this  better  understanding  of  the  field  comes  new 
problems  that  strain  against  the  limits  of  the  existing 
tools.  In  this  paper  we  will  outline  some  of  these  new 
problem  areas,  and  describe  what  new  research  needs  to 
be  done  to  to  meet  the  challenges  posed. 


1  Introduction 

The  history  of  the  application  of  formal  methods 
to  cryptographic  protocol  analysis  spans  nearly  twenty 
years,  and  recently  has  been  showing  signs  of  new 
maturity  and  consolidation.  A  number  of  specialized 
tools  have  been  developed,  and  others  have  effectively 
demonstrated  that  existing  general-purpose  tools  can 
also  be  applied  to  these  problems  with  good  results. 

However,  with  this  better  understanding  of  the  field 
comes  new  problems  that  strain  against  the  limits  of 
the  existing  tools.  Tools  as  they  exist  today  are  mainly 
intended  to  be  applied  to  the  problem  of  showing  that 
a  key  has  been  correctly  authenticated.  This  was  the 
usual  application  for  cryptographic  protocols  in  the 
past,  and  remains  a  common  one  today.  But  crypto¬ 
graphic  protocols  are  now  being  applied  to  new  types 
of  problems,  such  as  group  communication,  financial 


transactions,  and  negotiation  of  algorithms  as  well  as 
keys.  They  also  face  new  types  of  threats,  such  as  de¬ 
nial  of  service,  and  older  threats,  such  as  traffic  analy¬ 
sis,  that  are  becoming  more  prominent.  In  many  cases 
the  existing  tools  are  not  capable  of  dealing  with  these 
problems.  However  we  believe  that  many  of  the  ex¬ 
isting  techniques  could  be  adapted  so  they  could  be 
applied  successfully.  In  this  paper  we  will  outline  some 
of  these  new  areas,  and  describe  what  new  research 
needs  to  be  done  to  to  meet  the  challenges  posed. 

Many  of  the  ideas  on  new  directions  that  are  de¬ 
scribed  in  this  paper  were  developed  during  the  appli¬ 
cation  of  the  NRL  Protocol  Analyzer  to  the  analysis 
of  the  Internet  Key  Exchange  protocol  and  during  the 
development  of  a  set  of  formal  requirements  for  the  Se¬ 
cure  Electronic  Transactions  Protocols,  both  of  which 
were  done  as  part  of  the  DARPA  project  Formal  Anal¬ 
ysis  of  Internet  Security  Protocols.  One  of  the  purposes 
of  this  project  was  to  see  how  far  current  tools  could  be 
pushed  to  analyze  complex  protocols  that  must  satisfy 
new  types  of  requirements,  and  also  to  find  out  where 
our  tools  need  to  be  improved.  In  this  paper  we  show 
how  this  research  contributed  to  our  understanding  of 
the  areas  discussed  in  this  paper. 

The  rest  of  this  paper  is  organized  as  follows.  In 
Section  Two  we  give  a  brief  history  and  survey  of  the 
state  of  the  art  in  the  field.  In  Section  Three  we  de¬ 
scribe  the  NRL  Protocol  Analyzer  and  the  IKE  and 
SET  protocols  that  we  examined,  describing  the  fea¬ 
tures  that  made  them  a  challenge.  In  Section  Four  we 
describe  seven  different  emerging  areas:  open-ended 
protocols,  denial  of  service,  anonymous  communica¬ 
tion,  high  fidelity,  composability,  negotiation  of  com¬ 
plex  data  structures,  and  getting  the  products  of  our 
research  into  the  real  world.  Where  appropriate,  we  re¬ 
fer  back  to  our  work  on  IKE  and  SET  for  motivation. 
Section  Five  concludes  the  paper. 
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2  The  History  and  Current  State 
of  Formal  Cryptographic  Protocol 
Analysis  Tools 

Cryptographic  protocols  are  protocols  that  use  cryp¬ 
tography  to  distribute  keys  and  authenticate  principals 
and  data  over  a  network.  The  network  is  assumed  to 
be  hostile,  in  that  it  may  contain  intruders  who  can 
read,  modify,  and  delete  traffic,  and  who  may  have 
control  of  one  or  more  network  principals.  Because  of 
this,  such  protocols  are  often  subject  to  nonintuitive 
attacks  which  are  not  easily  apparent  even  to  a  care¬ 
ful  inspector,  especially  when  assumptions  about  the 
environment  in  which  the  protocol  operates  change. 
For  example,  as  is  pointed  out  in  [39],  the  Needham- 
Schroeder  public  key  protocol  [37] ,  which  was  intended 
to  be  used  for  communication  between  parties  that 
trust  each  other,  and  is  secure  as  long  as  those  assump¬ 
tions  hold,  become  subject  to  a  man-in-the-middle  at¬ 
tack  if  we  assume  that  one  of  the  communicating  par¬ 
ties  may  be  dishonest  [24],  an  assumption  which  has 
become  more  likely  in  a  web-based  environment. 

For  these  reasons,  it  has  long  been  realized  that  for¬ 
mal  methods  can  be  a  useful  method  for  analyzing  the 
security  of  cryptographic  protocols.  They  allow  one 
both  to  do  a  thorough  analysis  of  the  different  paths 
which  an  intruder  can  take,  and  to  specify  precisely 
the  environmental  assumptions  that  have  been  made. 
Probably  the  first  mention  of  formal  methods  as  a  pos¬ 
sible  tool  for  cryptographic  protocol  analysis  came  in 
Needham  and  Schroeder  [37].  However,  the  first  work 
that  was  actually  done  in  this  area  was  done  by  Dolev 
and  Yao  [10],  and  slightly  later  by  Dolev,  Even,  and 
Karp  [9],  who  in  the  late  seventies  and  early  eighties 
developed  a  set  of  polynomial-time  algorithms  for  de¬ 
ciding  the  security  of  a  restricted  class  of  protocols. 
Unfortunately,  it  was  soon  found  that  relaxing  the  re¬ 
strictions  on  the  protocols  even  slightly  made  the  secu¬ 
rity  problem  undecidable  [13],  and  so  the  work  did  not 
go  much  further  than  that.  Dolev  and  Yao’s  work  was 
significant,  however,  in  that  it  was  the  first  to  develop  a 
formal  model  of  an  environment  in  which  multiple  ex¬ 
ecutions  of  the  protocol  can  be  running  concurrently, 
in  which  cryptographic  algorithms  behave  like  black 
boxes  which  obey  a  limited  set  of  algebraic  properties 
(e.g.  the  encryption  and  decryption  operations  cancel 
each  other  out),  and  which  includes  an  intruder  who 
can  read,  alter,  and  destroy  traffic,  and  may  also  con¬ 
trol  some  legitimate  members  of  the  system.  Most  later 
work  on  the  formal  analysis  of  cryptographic  protocols 
is  based  on  this  model  or  some  variant  of  it. 

Shortly  later,  work  began  on  developing  tools  for  the 
analysis  of  security  protocols  in  general,  all  of  which 


were  based  on  the  Dolev- Yao  model  or  some  variant, 
including  the  Interrogator  [34] ,  the  NRL  Protocol  Ana¬ 
lyzer  [27],  and  the  the  Longlev- Rigby  tool  [23].  Others 
applied  general-purpose  formal  methods  to  the  prob¬ 
lem  [20].  Most  of  this  work  used  some  type  of  state 
exploration  technique,  in  which  a  state  space  is  defined 
and  then  explored  by  the  tool  to  determine  if  there 
are  any  paths  through  the  space  corresponding  to  a 
successful  attack  by  the  intruder.  Inductive  theorem 
proving  techniques  were  also  included  in  the  tool  in 
some  cases,  as  in  the  NRL  Protocol  Analyzer,  to  show 
that  the  size  of  the  search  space  was  sufficient  to  guar¬ 
antee  security.  Even  during  these  early  stages,  much 
of  this  work  was  successful  in  finding  flaws  in  protocols 
that  had  been  previously  undetected  by  human  ana¬ 
lysts,  including  the  use  of  the  NRL  Protocol  Analyzer 
to  find  a  flaw  in  the  Simmons  Selective  Broadcast  Pro¬ 
tocol  [27],  and  the  use  of  the  Longley- Rigby  tool  to  find 
a  flaw  in  a  banking  protocol  [23] . 

However,  this  still  remained  a  fairly  esoteric  area 
until  the  publication  of  the  Burrows,  Abadi,  and  Need¬ 
ham  logic  [5]  brought  the  problem  to  the  attention  of 
a  larger  research  community.  BAN  logic  uses  an  ap¬ 
proach  very  different  from  that  of  the  state  exploration 
tools.  It  is  an  example  of  a  logic  of  knowledge  and  be¬ 
lief,  which  consists  of  a  set  of  possible  beliefs  that  can 
be  held  by  principals  (such  as  a  belief  that  a  message 
was  sent  by  a  certain  other  principal),  and  a  set  of  in¬ 
ference  rules  for  deriving  new  beliefs  from  old  ones.  An 
example  would  be  a  rule  saying  that  if  A  believes  that 
a  key  I<  is  known  only  by  him  and  B,  and  A  receives  a 
message  encrypted  with  K,  than  A  believes  that  that 
message  was  sent  by  B  to  A,  or  by  A  to  B.  The  BAN 
logic  consisted  of  a  very  simple,  intuitive  set  of  rules, 
which  made  it  easy  to  use.  Even  so,  as  the  BAN  paper 
demonstrated,  it  was  possible  to  use  the  logic  to  pin¬ 
point  serious  flaws  in  protocols.  As  a  result,  the  logic 
gained  wide  attention  and  let  to  a  host  of  other  log¬ 
ics,  either  extending  BAN  logic  or  applying  the  same 
concept  to  different  types  of  problems  in  cryptographic 
protocols. 

Note  that  belief  logics  such  as  BAN  are  generally 
weaker  than  the  state  exploration  tools  since  they  op¬ 
erate  at  a  much  higher  level  of  abstraction.  Thus  inter¬ 
est  in  them  has  waned  somewhat  as  state  exploration 
systems  have  improved.  However,  they  have  an  advan¬ 
tage  in  that  they  are  usually  decidable  and  often  even 
efficiently  computable,  and  thus  can  be  completely  au¬ 
tomated,  as  has  been  shown  by  Brackin’s  Automated 
Authentication  Protocol  Analyzer  [3]. 

More  recently,  research  has  focused  on  state  explo¬ 
ration  tools  and  theorem  proving  techniques  based  on 
the  Dolev-Yao  model,  much  of  it  sparked  by  Lowe’s 


demonstration  that  it  was  possible  to  use  a  general- 
purpose  model  checker,  FDR,  to  find  a  man  in  the 
middle  attack  on  the  Needham-Schroeder  public  key 
protocol  [24],  Work  since  then  has  progressed  in  ap¬ 
plying  both  model  checkers  [36,  7]  and  theorem  provers 
[41,  12]  to  the  problem,  as  well  as  in  the  design  of 
special-purpose  model  checkers  [19,  43,  25]  and  the  use 
of  specialized  tools  originally  intended  for  somewhat 
different  applications  [11]. 

There  has  also  been  a  sign  of  consolidation  in  the 
area,  an  indication  that  it  has  been  maturing.  For  ex¬ 
ample,  Millen  has  been  developing  CAPSL  [35],  the 
Common  Authentication  Protocol  Language,  which  is 
intended  to  provide  a  common  specification  language 
for  cryptographic  protocol  analysis  tools.  Even  more 
recently,  Thayer,  Herzog,  and  Guttman  [14]  have  devel¬ 
oped  a  graph-theoretic  interpretation  of  the  Dolev-Yao 
model,  called  the  strand  space  model,  that  brings  to¬ 
gether  many  ideas  and  techniques  that  have  been  used 
in  the  formal  analysis  of  cryptographic  protocols.  Be¬ 
cause  of  this,  and  because  of  its  simplicity  and  elegance, 
it  has  begun  to  be  used  both  as  a  basis  for  new  special- 
purpose  tools  [43]  and  as  a  framework  in  which  to  ex¬ 
press  theoretical  results  [44] .  This  trend  has  promising 
implications  for  the  integration  of  future  tools  and  the 
incorporation  of  new  theoretical  results  into  these  tools. 

To  sum  up,  at  present  we  are  rapidly  approaching, 
if  we  have  not  already  reached,  a  state  in  which  we 
will  have  a  number  of  different  tools  available  that  will 
be  able  to  verify  safety  properties  such  as  authenti¬ 
cation  and  secrecy  by  performing  a  state  space  anal¬ 
ysis  of  a  protocol  specified  at  the  same  level  of  de¬ 
tail  that  is  normally  provided  in  a  journal  paper  using 
the  Dolev-Yao  model  of  a  protocol  attacker.  This  is 
not  everything;  such  tools  will  not  catch  errors  that 
arise  from  implementation  details  that  go  beyond  the 
journal-level  specification,  the  Dolev-Yao  model  leaves 
out  some  important  attacker  capabilities  such  as  crypt¬ 
analysis,  and,  since  the  Dolev-Yao  model  assumes  an 
intruder  that  is  capable  of  blocking  any  message,  it 
is  impossible  to  prove  any  kind  of  liveness  property. 
Nevertheless  this  is  still  a  great  deal;  the  wide  range  of 
attacks  found  by  such  tools  demonstrate  that  a  number 
of  nontrivial  problems  occur  at  this  level  of  specifica¬ 
tion. 

Since  the  protocol  security  problem  in  undecidable, 
[13,  18,  6],  the  analysis  tools  will  not  be  successful  all 
the  time,  and  they  may  require  human  intervention 
at  times.  But  even  so,  the  problem  of  tool  design  for 
this  area  seems  well  enough  understood  by  now  so  that 
these  limitations  should  not  interfere  too  much  with 
their  effective  use. 

Given  that  we  have  reached  this  plateau,  it  seems 


reasonable  at  this  point  to  ask,  what  comes  next?  And 
indeed,  there  are  a  number  of  related  problem  areas 
still  to  be  explored.  Some  of  them  have  only  surfaced 
in  the  last  few  years.  Others  have  been  known  about  for 
some  time,  but  it  was  thought  more  important  to  con¬ 
centrate  on  the  basics  first.  However,  now  that  the  ba¬ 
sics  are  well  understood,  it  is  time  to  look  more  closely 
at  some  of  these  areas.  In  the  remainder  of  this  paper 
we  do  this,  in  each  area  pointing  out  what  work  has 
already  done,  and  what  we  believe  still  remains  to  be 
done. 

3  IKE,  SET,  and  the  NRL  Protocol 
Analyzer 

3.1  Overview 

In  this  section  we  describe  the  IKE  and  SET  pro¬ 
tocols  that  we  analyzed  for  the  DARPA  project  For¬ 
mal  Analysis  of  Internet  Security  Protocols,  as  well  as 
the  tool  we  applied,  the  NRL  Protocol  Analyzer.  We 
concentrate,  not  on  the  analyses  themselves,  which  are 
described  elsewhere,  but  on  the  challenges  that  each 
posed.  We  identify  both  those  challenges  that  our  tools 
proved  capable  of  meeting,  and  those  areas  where  we 
felt  our  tools  fell  short. 

3.2  The  NRL  Protocol  Analyzer 

The  NRL  Protocol  Analyzer  is  a  formal  methods 
tool  for  analyzing  security  properties  of  cryptographic 
protocols.  It  uses  automatic  invariant  generation  to 
limit  a  potentially  infinite  search  space  in  combination 
with  exploration  of  the  remaining  space  to  generate  at¬ 
tacks  on  insecure  protocols  and  provide  security  proofs 
for  secure  ones,  even  in  the  face  of  a  potentially  un¬ 
limited  number  of  protocol  executions  or  an  unlimited 
number  of  intruder  actions. 

Protocols  in  the  Analyzer  model  are  specified  as 
communicating  state  machines,  one  of  which  is  a  hos¬ 
tile  intruder  following  the  Dolev-Yao  model  who  can 
read  all  traffic,  modify  or  delete  traffic,  perform  cryp¬ 
tographic  operations,  and  may  be  in  cooperation  with 
some  legitimate  users  of  the  system. 

The  user  of  the  Analyzer  attempts  to  determine 
whether  or  not  a  protocol  is  secure  by  specifying  an 
insecure  state.  This  state  can  be  specified  not  only  in 
terms  of  values  of  local  state  variables  and  terms  known 
by  the  intruder,  but  sequence  of  events  that  should  or 
should  not  have  occurred.  For  example,  the  user  could 
ask  the  Analyzer  to  look  for  a  state  in  which  the  same 
key  has  been  accepted  twice  by  a  principal  (two  events 
occurring)  or  a  state  in  which  a  responder  B  accepts  a 


key  as  good  for  communicating  by  an  initiator  .4,  but  in 
which  A  never  initiated  the  protocol  (one  event  having 
occurred  and  another  event  not  having  occurred  previ¬ 
ously)  .  The  Analyzer  works  backwards  from  that  state 
until  it  has  explored  the  search  space  exhaustively,  so 
that  each  path  produced  either  begins  in  an  initial  state 
(describing  an  attack)  or  an  unreachable  state.  Thus, 
like  the  other  tools  we  mentioned  earlier,  it  can  be 
used  fo  prove  safety  properties  such  that  no  party  is 
authenticated  incorrectly,  but  not  liveness  properties 
such  that  an  authentication  always  completes. 

The  Analyzer  makes  no  assumptions  about  limits  on 
the  number  of  protocol  executions,  the  number  of  prin¬ 
cipals  performing  the  different  executions,  the  number 
of  interleaved  executions,  or  the  number  of  times  cryp¬ 
tographic  functions  are  applied.  This  results  in  a  search 
space  that  is  originally  infinite.  However,  the  Analyzer 
provides  means  for  specifying  and  proving  inductive 
lemmas  about  the  unreachability  of  infinite  classes  of 
states.  This  allows  the  user  to  narrow  down  the  search 
space  so  that  in  many  cases  an  exhaustive  search  is 
possible. 

We  also  made  use  of  the  NRL  Protocol  Analyzer 
Temporal  Requirements  Language  (NPATRL)  [48]. 
NPATRL  is  a  temporal  logic  language  allowing  us  to 
specify  desirable  protocol  properties  in  terms  of  desir¬ 
able  or  undesirable  sequence  of  events.  An  NPATRL 
requirement  is  applied  to  the  NRL  Protocol  Analyzer 
by  taking  the  negation  of  the  requirement  and  using 
that  as  an  insecure  state  for  the  Analyzer  to  prove  un¬ 
reachable. 

The  Analyzer  has  been  applied  to  a  number  of  dif¬ 
ferent  cryptographic  protocols,  and  has  found  flaws  in 
several.  In  some  cases  the  flaws  had  not  been  discov¬ 
ered  before.  Examples  of  protocols  the  Analyzer  has 
been  used  to  examine  are  the  Simmons  Selective  Broad¬ 
cast  Protocol  [27],  the  Burns-Mitchell  Ticket  Granting 
Protocol  [32],  and  an  early  version  of  the  Encapsulat¬ 
ing  Security  Protocol  [46] .  The  Analyzer  has  also  been 
used  to  prove  security  properties  of  a  number  of  other 
protocols,  by  performing  an  exhaustive  search  of  the  fi¬ 
nite  space  that  is  left  after  the  necessary  lemmas  have 
been  proved  (see  [28,  29].  A  more  detailed  description 
of  the  Analyzer  is  given  in  [33] . 

The  NRL  Protocol  Analyzer,  as  we  see,  operates 
within  the  same  paradigm  as  most  specialized  tools  for 
cryptographic  protocol  analysis,  and  indeed,  was  one 
of  the  first  tools  to  make  use  of  it.  That  is,  it  is  based 
on  the  Dolev-Yao  model  and  it  concentrates  mainly 
on  proving  authentication  properties.  Thus  it  is  well 
suited  for  testing  the  limits  of  that  paradigm. 


3.3  IKE 

The  Internet  Key  Exchange  protocol  (IKE)  is  a  key 
exchange  protocol  being  developed  by  the  IP  Security 
Protocol  (IPSEC)  Working  Group  of  the  Internet  En¬ 
gineering  Task  Force  (IETF).  It  is  intended  to  provide 
the  security  support  for  client  protocols  of  the  Inter¬ 
net  Protocol.  As  such,  it  does  much  more  than  simply 
distribute  keys;  it  also  is  intended  to  be  used  to  estab¬ 
lish  Security  Associations  that  specify  such  things  as 
the  protocol  format  used,  the  cryptographic  and  hash¬ 
ing  algorithms  used,  and  other  necessary  features  for 
secure  communication.  Since  it  is  intended  to  be  flexi¬ 
ble,  it  supports  a  number  of  different  types  of  key  ex¬ 
change  options,  including  digital  signatures,  public  key 
encryption,  and  conventional  encryption  using  shared 
keys.  The  DifEe-Hellman  algorithm  is  used  to  gener¬ 
ate  shared  key  material,  but  is  optional  in  some  cases. 
IKE  has  evolved  from  a  number  of  different  protocols, 
including  ISAKMP  [26],  Oakley  [38],  the  Station-to- 
Station  protocol  [8],  and  SKEME  [21],  the  last  two  of 
which  influenced  the  development  of  Oakley. 

A  typical  key  establishment  protocol  proceeds  in  one 
phase,  in  which  two  parties  use  master  keys  to  estab¬ 
lish  shared  keying  material.  IKE,  however,  proceeds  in 
two  such  phases.  In  the  first  phase,  two  entities  use 
master  keys  to  agree,  not  only  on  keying  material,  but 
on  the  various  mechanisms  (e.g.  cryptographic  algo¬ 
rithms,  hash  functions,  etc.),  that  they  will  use  in  the 
second  phase.  The  keying  material  and  set  of  mech¬ 
anisms  thus  agreed  upon  is  called  a  security  associa¬ 
tion.  In  the  first  phase  protocol,  the  initiator  proposes 
a  number  of  possible  security  associations  to  the  re¬ 
sponder,  who  picks  one.  In  the  second  phase,  the  keys 
and  mechanisms  produced  in  the  first  phase  are  used 
to  agree  upon  new  keys  and  mechanisms  that  will  be 
used  to  protect  and  authenticate  further  communica¬ 
tions.  The  security  association  established  in  Phase 
One  is  bidirectional,  so  the  initiator  in  the  first  phase 
can  be  either  initiator  or  responder  in  the  second  phase. 

At  the  time  we  analyzed  IKE,  it  could  be  used  in 
four  different  modes:  main  mode,  aggressive  mode, 
quick  mode,  and  new  group  mode.  Main  and  aggressive 
modes  are  used  in  Phase  One  negotiations,  quick  mode 
is  used  in  Phase  Two  negotiations,  and  New  Group 
Mode  is  used  to  change  the  Diffie-Hellman  group.  Both 
main  and  aggressive  mode  can  be  implemented  using 
several  different  types  of  authentication;  there  is  a  dif¬ 
ferent  protocol  for  each  one. 

The  main  goals  of  IKE  are  the  authentication  of 
security  associations,  and  the  authentication  and  gen¬ 
eration  of  keys.  However,  IKE  has  some  other  sec¬ 
ondary  goals,  as  well.  A  good  deal  of  thought  has 


gone  into  making  IKE  resistant  to  denial  of  service 
attacks  by  preventing  it  from  requiring  principals  to 
engage  in  resource-intensive  activities  until  a  “reason¬ 
able”  amount  of  authentication  has  occurred.  IKE  is 
also  designed  to  be  somewhat  resistant  to  traffic  anal¬ 
ysis,  in  that  in  Main  Mode  identities  are  encrypted. 

In  our  analysis  of  IKE,  described  in  detail  in  [29], 
we  concentrated  on  verifying  that  keys  were  properly 
authenticated,  and  that  portions  of  the  Security  As¬ 
sociations  were  authenticated.  We  did  not  attempt  to 
verify  to  what  degree  the  protocol  resistant  to  traffic 
analysis  or  denial  of  service;  this  was  beyond  the  scope 
of  our  tool.  However,  it  is  clear  that  such  an  analy¬ 
sis  would  have  been  useful.  These  issues  are  discussed 
in  more  detail  in  Section  4.2  on  Denial  of  Service  and 
Section  4.3  on  Anonymous  Communication. 

One  of  the  main  challenges  in  analyzing  IKE  was  the 
sheer  proliferation  of  related  subprotocols.  Since  we 
wanted  to  verify,  among  other  things,  that  one  proto¬ 
col  could  not  be  confused  with  another,  we  analyzed  as 
many  subprotocols  together  as  we  possibly  could.  The 
NRL  Protocol  Analyzer  proved  adequate  to  this  task, 
but  not  before  undergoing  a  major  overhaul  designed 
to  increase  its  robustness,  and  some  serious  thinking 
about  how  to  identify  possible  interactions.  These  is¬ 
sues  are  discussed  in  depth  in  Section  4.5  on  Compos- 
ability. 

3.4  SET 

The  SET  Protocol  [31]  is  a  protocol  sponsored  by 
major  credit  card  companies  and  others  that  is  in¬ 
tended  to  provide  a  standard  for  safe,  secure  credit  card 
transactions  over  the  Internet.  (‘SET’  stands  for  ‘Se¬ 
cure  Electronic  Transactions’.)  As  such,  it  is  intended 
to  supply  an  electronic  version  of  the  paper  system  that 
exists  today.  However,  there  are  a  number  of  risks  con¬ 
nected  with  use  of  the  Internet  that  do  not  arise  in  the 
paper  world,  or  at  least  are  not  considered  as  severe. 
These  arise  from  the  difficulty  of  identifying  partici¬ 
pants  in  transactions  and  the  difficulty  of  ensuring  the 
private  information  sent  over  the  Internet  remains  so. 
SET  is  intended  to  reduce  these  risks  by  introducing 
cryptographic  means  to  protect  sensitive  information 
such  as  credit  card  numbers  and  to  provide  authenti¬ 
cation  of  parties  involved  in  a  credit  card  transaction. 

A  payment  transaction  in  the  SET  protocol  involves 
three  parties:  a  customer,  a  merchant,  and  an  applica¬ 
tion  payment  gateway.  The  customer  presents  a  pur¬ 
chase  request  to  the  merchant,  which  includes  credit 
card  information  and  a  proposed  purchase  amount. 
The  purchase  request  is  identified  with  a  transaction 
ID.  The  merchant  then  passes  the  request  along  to 


the  gateway,  together  with  a  request  that  a  certain 
amount  (not  necessarily  equal  to  the  purchase  amount) 
be  authorized.  The  gateway  then  checks  the  customer’s 
credit,  authorizes  a  certain  amount,  and  passes  this  in¬ 
formation  back  to  the  merchant.  The  merchant  passes 
this  information  back  to  the  customer.  Either  at  the 
same  time  as  the  authorization  request,  or  later,  the 
merchant  presents  a  capture  request  to  the  gateway  for 
the  same  transaction,  requesting  that  a  certain  amount 
of  money  be  captured.  The  gateway  approves  a  certain 
amount  which  may  or  may  not  be  equal  to  the  amount 
requested.  The  merchant  then  passes  this  information 
back  to  the  customer. 

The  authentication  structure  of  the  SET  protocol  is 
complex.  Messages  between  merchant  and  gateway  are 
always  authenticated  using  digital  signatures,  as  are 
messages  from  the  merchant  to  the  customer.  Digital 
signatures  for  authentication  for  messages  from  cus¬ 
tomer  to  merchant  are  optional,  although  they  may  be 
made  mandatory  by  a  particular  application.  However, 
it  is  in  the  authentication  of  forwarded  messages  that 
the  structure  really  becomes  interesting.  The  message 
from  customer  to  merchant  includes  information  that 
is  needed  by  the  gateway  but  may  be  hidden  from  the 
merchant,  such  as  credit  card  number  (PAN,  i.e.,  Pri¬ 
mary  Account  Number)  and  expiration  date.  Also  in¬ 
cluded,  when  customer  digital  signatures  are  used,  is  a 
data  item  called  the  PANSecret,  which  is  known  only 
by  the  customer  and  gateway,  but  not  the  merchant. 
This  is  not  available  when  customer  digital  signatures 
are  not  used,  since  it  is  generated  as  part  of  the  certifi¬ 
cate  registration  process.  This  information  is  protected 
by  the  use  of  a  dual  signature.  Two  hash  functions  are 
computed,  one  over  the  the  data  to  be  kept  hidden 
from  the  merchant,  and  the  other  over  the  data  to  be 
revealed  to  it,  which  includes  a  hash  over  the  purchase 
amount  and  order  description  that  the  customer  and 
merchant  agreed  to  offline.  The  hidden  data  is  en¬ 
crypted  using  the  gateway’s  public  key.  The  customer 
then  computes  a  digital  signature  (if  customer  signa¬ 
tures  are  used)  over  the  two  hashes.  The  signature, 
the  two  hashes,  and  the  encrypted  and  unencrypted 
information  are  sent  to  the  merchant.  The  merchant 
verifies  the  signature  and  forwards  the  information,  in¬ 
cluding  the  signature  if  any,  to  the  gateway.  When 
the  gateway  receives  the  message,  it  verifies  the  signa¬ 
ture,  if  any,  and  also  verifies  the  PAN  and  PANSecret. 
Whether  or  not  signatures  are  used,  it  also  verifies  the 
PAN  and  and  the  customer’s  portion  of  the  PANSecret 
(if  any)  with  the  credit  card  issuer,  although  this  may 
be  done  offline. 

Authentication  of  gateway  to  customer  via  the  mer¬ 
chant  is  much  simpler:  there  is  none.  Any  information 


from  the  gateway  that  the  merchant  passes  on  to  the 
customer  is  authenticated  only  by  the  merchant’s  sig¬ 
nature. 

There  are  also  a  number  of  options  available.  A 
customer  has  the  option  of  sending  an  initialization 
message  prior  to  its  purchase  request,  which  allows  it 
to  obtain  more  up-to-date  certificates  from  the  mer¬ 
chant,  and  allows  the  merchant  to  send  back  a  ran¬ 
dom  challenge  which  it  can  use  to  verify  the  freshness 
of  the  customer’s  subsequent  purchase  request.  When 
an  initialization  message  is  sent,  the  transaction  ID  is 
jointly  created  by  customer  and  merchant.  When  no 
initialization  message  is  sent,  the  customer  may  create 
the  transaction  ID,  or  it  may  be  jointly  created  by  the 
customer  and  merchant.  The  gateway  also  has  the  op¬ 
tion,  depending  upon  the  policy  followed,  of  sending 
the  customer’s  PAN  to  the  merchant  (the  PANSecret, 
however,  is  never  sent).  There  are  also  protocols  for 
inquiring  about  the  status  of  an  order,  cancelling  an 
order,  etc. 

We  have  not  yet  completed  our  analysis  of  SET,  but 
we  have  written  a  formal  specification  of  the  SET  re¬ 
quirements  using  the  NPATRL  requirements  language 
[31].  This  turned  out  to  be  a  nontrivial  task.  Although 
the  NPATRL  language  was  expressive  enough  to  state 
the  requirements,  their  complexity  meant  that  any  such 
specification  would  be  incomprehensible  unless  we  in¬ 
troduced  some  higher-level  framework  in  which  to  or¬ 
ganize  it.  We  describe  the  problem  and  our  solution  in 
more  detail  in  Section  4.6  on  Negotiation  of  Complex 
Data  Structures. 

4  Emerging  Problems 

4.1  Open-Ended  Protocols 

Most  of  the  work  on  the  formal  analysis  of  crypto¬ 
graphic  protocols  has  concentrated  on  protocols  that 
involve  the  communication  of  a  fixed  number  of  prin¬ 
cipals:  for  example,  an  initiator  and  a  responder  in  a 
key  agreement  protocol,  or  a  customer,  merchant,  and 
bank  in  an  electronic  commerce  protocol.  Most  data 
structures  that  are  used  are  also  closed-ended.  That 
is,  in  general  each  message  is  a  fixed  structure  that  is 
composed  of  a  bounded  number  fields  containing  data 
such  as  nonces,  names,  keys,  etc.  Open-endedness  is 
included  in  the  protocol  model,  but  only  with  respect 
to  the  number  of  protocol  executions  that  may  be  going 
on  at  the  same  time,  or  the  number  of  operations  that 
the  intruder  may  perform  to  create  a  message.  This 
means  that  the  protocol  models  do  not  need  to  include 
such  constructs  as  loops,  thus  simplifying  the  model 
and,  one  hopes,  the  analysis. 


However,  open-ended  structures  are  beginning  to 
show  up  in  a  number  of  different  applications.  By  open- 
ended,  we  simply  mean  the  the  structure  may  include 
an  arbitrarily  large  number  of  data  fields;  no  precise 
limit  is  put  on  them  by  the  protocol  specification.  The 
most  obvious  is  in  group  communication  protocols,  in 
which  keys  must  be  shared  among  members  of  a  group 
of  arbitrary  size.  Here,  it  is  the  group  of  principals 
that  may  be  participating  in  a  particular  instance  of 
the  protocol  that  is  open-ended.  However,  open-ended 
structures  show  up  in  other  types  of  protocols,  as  well. 
For  example,  anonymous  routing  protocols  make  use  of 
an  arbitrary  number  of  routers  to  achieve  their  goals. 
Open-ended  structures  are  also  used  even  in  protocols 
in  which  the  number  of  principals  is  bounded.  For  ex¬ 
ample,  the  SET  protocol  allows  a  merchant  to  batch 
transactions  for  approval  by  a  security  gateway.  The 
IKE  Protocol  offers  an  even  more  complex  example. 
One  of  the  purposes  of  IKE  is  to  agree  on  a  security 
association  (SA),  the  collection  of  algorithms  and  other 
information  used  to  encrypt  and  authenticate  data.  Al¬ 
though  there  is  some  information  that  an  SA  must  in¬ 
clude,  there  is  no  defined  limit  on  what  it  can  include, 
so  its  definition  is  left  open-ended.  In  addition,  an  SA 
is  negotiated  by  having  the  initiator  present  a  list  of 
SAs  to  a  responder,  who  then  picks  one.  Thus  there  are 
two  sources  of  open-endedness  in  the  use  of  SAs.  More¬ 
over,  this  open-endedness  is  security-relevant.  For  ex¬ 
ample,  recently  Zhou  [54]  and  independently  Ferguson 
and  Schneier  [15]  found  an  attack  in  which  an  intruder 
could  trick  an  initiator  into  agreeing  on  the  wrong  SA 
by  making  use  of  the  fact  that  only  part  of  the  SA  is 
actually  used  in  IKE  itself. 

So  far,  there  has  been  very  little  work  on  applying 
formal  analysis  techniques  to  these  kinds  of  problems 
in  cryptographic  protocols.  One  notable  exception  has 
been  the  work  of  Paulson  [40]  on  the  application  of 
the  Isabelle  theorem  prover  to  the  analysis  of  a  pro¬ 
tocol  that  involves  an  arbitrary  number  of  principals, 
and  the  work  of  Bryans  and  Schneider  [4]  applying  the 
PVS  theorem  prover  to  the  same  protocol.  Since  all 
of  this  work  involves  general-purpose  theorem  provers 
instead  of  special-purpose  tools,  we  would  not  be  sur¬ 
prised  to  find  that  the  authors  were  able  to  make  use 
of  techniques  that  were  not  available  in  tools  that  were 
specifically  designed  for  cryptographic  protocol  anal¬ 
ysis.  However,  it  is  heartening  to  note  that  Bryan 
and  Schneider’s  work  makes  use  of  a  construct,  the 
rank  function,  that  Schneider  had  previously  devel¬ 
oped  for  the  analysis  of  cryptographic  protocols  that 
involved  only  a  bounded  number  of  participants  in  a 
single  protocol  execution.  Thus  it  may  be  the  case 
that  techniques  that  were  developed  to  deal  with  the 


unboundedness  that  arises  first  out  of  the  ability  of  an 
intruder  to  perforin  an  arbitrary  number  of  message 
operations,  and  secondly  out  of  the  possible  execution 
of  an  unbounded  number  of  protocol  operations  in  par¬ 
allel,  should  be  applicable  to  other  types  of  open-ended 
protocols  as  well,  although  they  will  probably  require 
some  adaptation  and  expansion. 

4.2  Denial  of  Service 

Denial  of  service  was  not  a  threat  that  was  a  cause 
of  much  concern  to  the  first  designers  of  cryptographic 
protocols.  However,  as  we  have  seen  from  the  SYN  at¬ 
tacks  of  TCP/IP,  many  communication  protocols  are 
subject  to  a  particular  type  of  denial  of  service  attack 
in  which  the  attacker  initiates  an  instance  of  a  pro¬ 
tocol  and  then  drops  out,  leaving  the  victim  hanging. 
Since  the  victim  must  use  resources  to  keep  the  connec¬ 
tion  open  until  the  protocol  times  out,  the  attacker,  by 
initiating  and  then  dropping  enough  instances  in  the 
protocol  quickly  enough,  can  cause  the  victim  to  waste 
enough  resources  keeping  connections  open  so  that  it  is 
unable  to  participate  in  any  more  instances  of  the  pro¬ 
tocol  and  is  thus  effectively  cut  off  from  the  network. 

Strong  authentication  can  both  ameliorate  and  ex¬ 
acerbate  this  problem.  Authentication  can  be  used  to 
identify  the  source  of  the  attack,  allowing  the  victim 
to  cut  off  communication  with  the  attacker.  But  au¬ 
thentication  can  also  be  used  as  a  means  of  launching 
denial  of  service  attacks,  since  it  is  both  computation 
and  storage-intensive,  and  the  attacker  could  launch  a 
denial  of  service  attack  on  a  victim  by  sending  it  a  se¬ 
ries  of  incorrectly  authenticated  messages  that  it  would 
waste  its  resources  verifying. 

The  approach  that  has  been  taken  to  resolving  this 
problem  is  to  use  a  tradeoff  between  resources  required 
of  the  victim  (referred  to  from  now  on  as  the  “de¬ 
fender”)  with  resources  required  of  the  intruder.  Early 
parts  of  the  protocol  require  weak  authentication  that 
do  not  require  great  resources  on  the  part  of  the  in¬ 
truder  to  break,  but  require  fewer  resources  on  the  part 
of  the  defender  to  verify.  More  expensive  forms  of  au¬ 
thentication  are  reserved  for  later  in  the  protocol  when 
a  degree  of  assurance  that  the  participating  parties  are 
legitimate  are  obtained. 

Note  that  the  attacker  model  used  in  this  strategy 
is  generally  weaker  than  the  model  used  in  the  verifica¬ 
tion  of  traditional  authentication  goals.  Thus  the  sort 
of  nonintuitive  attacks  that  have  been  found  on  these 
types  of  goals  will  not  necessarily  arise  in  the  case  of  de¬ 
nial  of  service,  although  they  are  not  ruled  out  entirely. 
However,  the  analysis  becomes  more  complicated  in  a 
number  of  other  ways.  First,  the  protocol  must  be  an¬ 


alyzed,  not  only  in  terms  of  its  final  goals,  but  along 
each  step  of  the  way.  Every  time  a  a  principal  takes 
part  in  some  action  that  requires  the  use  of  a  signifi¬ 
cant  amount  of  resources,  one  must  check  that  that  an 
attacker  could  not  fraudulently  cause  that  principal  to 
reach  that  step  without  spending  a  significant  amount 
of  its  own  resources.  Secondly,  in  order  to  make  that 
verification  possible,  it  is  necessary  to  have  a  model, 
not  only  of  principal  and  intruder  actions,  but  of  the 
cost  of  those  actions.  Thus  some  sort  of  formal  analy¬ 
sis  technique  would  be  beneficial,  simply  in  order  to  to 
keep  track  of  this  complex  multi-stage  analysis. 

Existing  protocol  analysis  tools,  although  they  can¬ 
not  be  applied  to  the  problem  directly  in  their  present 
form,  have  many  features  that  could  be  useful  if 
adapted  properly.  For  example,  for  most  it  is  possi¬ 
ble  to  specify  intermediate  as  well  as  ultimate  goals. 
Also,  although  most  use  a  single  model  of  the  intruder, 
most  of  the  weaker  intruder  models  that  would  be 
used  would  be  restrictions  of  this  more  general  intruder 
model. 

We  have  been  working  on  a  framework  [30]  that 
could  be  used  to  apply  existing  tools,  appropriately 
modified,  to  the  denial  of  service  problem.  We  make 
use  of  the  concept  developed  by  Gong  and  Svverson 
[17]  of  a  fail-stop  cryptographic  protocol.  Briefly,  a 
protocol  is  fail-stop  if,  whenever  an  attacker  interferes 
with  a  message,  this  is  detected  by  the  receiving  prin¬ 
cipal  and  the  protocol  is  halted.  We  have  modified  the 
fail-stop  model  to  include  an  attacker  whose  capabili¬ 
ties  change  as  the  protocol  progresses,  and  have  devel¬ 
oped  a  framework  for  trading  off  intruder  capabilities 
against  effort  expended  by  the  defenders.  In  this  frame¬ 
work  the  protocol  designer  specifies  a  protocol  tolerance 
relation ,  which  describes  how  much  effort  he  believes 
it  should  be  necessary  to  expend  against  an  attacker 
of  a  given  strength.  Since  we  are  developing  a  frame¬ 
work  for  models  instead  of  a  specific  model,  we  do  not 
specify  exactly  how  this  effort  should  be  quantified,  but 
examples  would  include  amount  of  resources  expended, 
amount  of  time  expended,  or  amount  of  computational 
power  required.  A  protocol  is  then  designed  so  that 
the  effort  expended  by  the  defender  increases  as  the 
protocol  executes,  and  also  as  each  message  is  verified. 
The  protocol  is  then  analyzed  to  show  that  it  is  fail- 
stop  against  an  attacker  whose  capabilities  are  within 
the  constraints  of  the  desired  tolerance  relation.  That 
is,  at  each  verification  point,  the  amount  of  effort  re¬ 
quired  by  the  attacker  to  spoof  the  verification,  versus 
the  amount  of  effort  wasted  by  the  defender  if  the  ver¬ 
ification  is  successfully  spoofed,  should  fall  within  the 
tolerance  relation. 


4.3  Anonymous  Communication 

Anonymous  communication  is  an  application  that 
has  recently  begun  to  move  from  the  laboratory  to  the 
real  world,  as  the  ubiquity  of  the  World  Wide  Web 
makes  even  ordinary  users  more  sensitive  to  the  dan¬ 
gers  of  traffic  analysis  and  of  indiscriminately  reveal¬ 
ing  personal  information  over  the  Web.  Thus  systems 
such  as  the  Onion  Router  [16],  the  Anonymizer  and 
Crowds  [42],  are  designed  to  prevent  an  onlooker  from 
determining  the  origination  or  destination  of  requests 
to  servers.  Basically  the  way  all  these  systems  work  is 
by  having  requests  from  users  routed  through  one  or 
more  nodes.  In  the  simplest  versions,  a  user  proxies  a 
request  through  a  single  site,  which  strips  the  request  of 
identifying  data  or  otherwise  disguises  its  source,  and 
forwards  it  to  the  server.  More  sophisticated  systems, 
such  as  Crowds  and  Onion  Routing,  have  the  request 
routed  through  a  number  of  nodes.  Onion  Routing  uses 
cryptographic  means  to  keep  each  node  ignorant  of  all 
other  nodes  in  the  path  except  the  ones  with  which  it 
communicates  directly. 

Other  systems  provide  other  types  of  anonymity. 
Proxymate  distributes  pseudonyms  for  dealing  with 
third  parties.  The  Rewebber  supports  anonymous 
publishing.  Anonymous  remailers  support  anonymous 
email.  Indeed,  we  can  safely  assume  that,  for  any 
application  involving  communication  over  the  Inter¬ 
net,  there  are  situations  in  which  one  might  be  con¬ 
cerned  about  preserving  anonymity  and  preventing 
traffic  analysis. 

We  note  that  anonymity  has  properties  that  make 
it  challenging  to  analyze.  First  of  all,  it  is  an  emergent 
property,  that  is,  one  that  is  not  apparent  in  isolation. 
It  would  be  hard  to  disguise  the  source  of  a  request  if 
it  is  the  only  request  in  the  network,  no  matter  how 
many  nodes  it  was  routed  through.  An  anonymizing 
protocol  depends  upon  a  mix  of  traffic  to  disguise  the 
source  and  destination  of  any  particular  item.  Statisti¬ 
cal  studies,  such  as  the  work  of  Timmerman  [51],  will 
be  of  use  here  to  determine  how  well  this  strategy  works 
in  different  situations.  Previous  work  done  on  the  anal¬ 
ysis  of  covert  channels  in  networks  [52]  might  also  be  of 
use  here,  if  applied  properly.  Next,  the  more  powerful 
anonymizing  protocols  require  communication  between 
an  arbitrary  number  of  nodes,  instead  of  just  two  or 
three,  whic  is  the  number  of  principals  that  are  usually 
assumed  to  be  communicating  in  most  of  the  proto¬ 
cols  that  have  been  analyzed  using  the  existing  cryp¬ 
tographic  protocol  analysis  tools.  Thus  any  techniques 
that  are  developed  for  analyzing  group  communication 
protocols  will  probably  also  be  useful  in  this  area.  Fi¬ 
nally,  since  an  anonymity  protocol  attempts  to  preserve 


secrecy  by  distributing  the  data  over  a  wide  area,  the 
assumptions  made  about  the  capacities  of  an  attacker 
are  very  relevant.  A  ubiquitous  attacker  will  be  able  to 
break  most  anonymity  protocols,  but  ubiquity  is  not 
a  very  realistic  assumption.  However,  attackers  who 
only  reside  at  single  nodes  and  do  not  communicate 
are  not  very  realistic  either.  The  work  by  Syverson 
and  Stubblebine  on  group  principals  [47]  deals  with 
some  aspects  of  this  problem,  introducing  the  notion 
of  a  group  principal  that  consists  of  a  certain  number 
of  members  who  are  assumed  to  have  certain  specified 
capacities  for  sharing  knowledge. 

In  summary,  we  believe  that  the  analysis  of 
anonymity  protocols  pose  a  new  research  challenges 
which  are  beginning  to  be  met,  at  least  partially  and 
in  different  aspects.  The  main  challenge  may  be  tying 
these  different  threads  together. 

4.4  High  Fidelity 

Most  work  on  the  application  of  formal  methods  to 
cryptographic  protocol  analysis  have  modeled  proto¬ 
cols  at  a  very  high  level  of  abstraction.  Techniques 
based  on  state  reachability  analysis  usually  assume 
that  the  algorithms  used  behave  like  black  boxes,  with 
only  enough  algebraic  properties  included  (e.g.  that 
encryption  and  decryption  cancel  each  other  out)  to 
allow  the  protocol  to  function  correctly.  Techniques 
based  on  belief  logics  are  usually  even  more  abstract, 
forgoing  in  most  cases  even  a  general  explicit  model  of 
the  intruder  or  of  the  cryptographic  operations;  instead 
goals  achieved  by  the  protocol  are  derived  directly  from 
the  messages  sent. 

However,  it  is  well  known  that  many  security  prob¬ 
lems  in  protocols  arise  at  a  much  lower  level  of  abstrac¬ 
tion.  Some  come  from  interactions  of  the  cryptosys¬ 
tem  with  the  protocol,  such  as  a  protocol  that  includes 
known  or  chosen  plaintext  while  using  a  cryptographic 
algorithm  that  may  be  vulnerable  to  attacks  based  on 
the  inclusion  of  this  type  of  plaintext.  Others  come 
from  problems  with  other  supporting  algorithms,  such 
as  hash  functions  or  modes  of  encryption.  Some  come 
from  other  types  of  low-level  implementation  details. 
For  example,  in  our  analysis  of  the  Internet  Key  Ex¬ 
change  protocol,  we  found  an  attack  that  would  work 
if  a  recipient’s  decision  as  to  the  possible  source  of  a 
message  was  implemented  in  one  way,  but  would  fail  if 
it  was  implemented  in  another  way.  Thus,  it  appears 
to  be  well  worth  our  while  to  take  our  analysis  to  a 
lower  level  of  abstraction. 

Some  work  in  this  direction  already  exists.  For  ex¬ 
ample,  work  on  the  analysis  of  modes  of  encryption 
and  chosen  and  known  plaintext  has  been  successful 


both  in  finding  new  problems  [45]  and  reproducing 
known  attacks  [46].  From  an  entirely  different  angle, 
work  has  also  been  ongoing  on  introducing  some  of  the 
polynomial-time  reduction  techniques  used  by  cryptog¬ 
raphers  into  the  framework  used  by  formal  methods, 
making  it  possible  to  reason  more  precisely  about  the 
interaction  of  a  protocol  with  the  cryptographic  algo¬ 
rithms  that  is  uses  [22]  Finally,  recently  new  interest 
has  been  shown  in  revisiting  the  problems  of  secrecy 
models  in  cryptographic  protocols,  thus  going  beyond 
the  standard  black-box  assumptions  [53].  Thus  we  see 
new  interest  in  the  problem  of  high  fidelity  from  a  num¬ 
ber  of  different  sides. 

4.5  Composability 

Most  work  on  the  analysis  of  cryptographic  proto¬ 
cols  has  concentrated  on  the  analysis  of  protocols  that 
can  be  described  in  terms  of  a  single  sequence  of  mes¬ 
sages  without  any  choice  points  or  loops.  However, 
most  cryptographic  protocols  are  not  actually  deployed 
in  this  fashion.  Indeed,  many  cryptographic  protocols 
as  they  are  actually  implemented  can  be  thought  of  as  a 
suite  of  “straight-line”  sub-protocols  (that  is  protocols 
that  involve  no  if-then-elses  and  no  loops)  along  with  a 
number  of  choice  points  in  which  the  user  may  choose 
which  sub-protocol  to  execute.  In  this  kind  of  environ¬ 
ment,  it  is  necessary,  not  only  that  each  subprotocol 
be  shown  to  execute  correctly  in  isolation,  but  that  the 
subprotocols  do  not  interact  with  each  other  in  harm¬ 
ful  ways.  This  problem  in  its  general  form  is  known  as 
the  composition  problem  for  cryptographic  protocols: 
given  that  two  or  more  different  protocols  are  executing 
in  the  same  environment,  is  it  possible  that  a  message 
or  messages  from  one  protocol  could  be  used  to  subvert 
the  goals  of  the  other? 

The  composability  problem  is  not  only  a  theoretical 
concern.  Consider,  for  example,  the  following  attack, 
described  in  [1]  on  a  very  early  version  of  SSL.  The 
early  version  included  an  optional  client  authentica¬ 
tion  phase  in  which  the  client’s  challenge  response  was 
independent  of  the  type  of  cipher  negotiated  for  the 
session,  and  also  of  whether  or  not  the  authentication 
was  being  performed  for  a  reconnection  of  an  old  ses¬ 
sion  or  for  a  new  one.  Moreover,  this  version  of  SSL 
allowed  the  use  of  cryptographic  algorithms  of  various 
strength  (weak  algorithms  for  export  and  stronger  ones 
for  home  use) ,  and  since  weakness  could  be  guaranteed 
by  revealing  part  of  the  key,  it  was  not  always  clear 
by  inspection  of  the  key  whether  weak  or  strong  cryp¬ 
tography  was  being  used.  This  allowed  the  following 
attack  (note  that  in  this  version  of  SSL,  session  keys 
were  supplied  by  the  client): 


1.  A  key  K  is  agreed  upon  for  session  A  using  weak 
cryptography. 

2.  Key  K  is  broken  by  the  intruder  in  real  time. 

3.  The  client  initiates  a  reconnection  of  session  A. 

4.  The  intruder  initiates  a  new  session  B,  pretend¬ 
ing  to  be  the  client,  using  strong  cryptography  to¬ 
gether  with  the  compromised  key  K. 

5.  As  part  of  the  connection  negotiations  for  session 
B,  the  server  presents  a  challenge  to  the  client. 
The  client  should  return  a  digital  signature  of  both 
K  and  the  challenge.  The  intruder  can’t  do  this 
itself,  but  it  can  pass  the  server’s  request  on  to  the 
client,  who  will  take  it  to  be  part  of  the  reconnec¬ 
tion  negotiations  for  session  A,  and  produce  the 
appropriate  response.  The  intruder  passes  the  re¬ 
sponse  on  to  the  server  as  part  of  the  session  B 
negotiations,  and  the  protocol  completes. 

6.  If  the  client  would  have  been  given  access  to  special 
privileges  as  a  result  of  using  strong  cryptography, 
this  could  lead  to  the  intruder  gaining  privileges 
that  it  should  not  be  able  to  have  by  breaking  the 
key  K. 

Since  this  attack  involves  a  confusion  of  the  recon¬ 
nection  protocol  with  the  connection  protocol,  it  is  an 
example  of  a  failure  of  composition  which  would  not 
have  been  found  if  the  two  protocols  had  been  ana¬ 
lyzed  separately. 

Early  work  on  composability  [18,  17]  concentrated 
on  determining  under  what  conditions  protocols  could 
be  guaranteed  to  be  composable.  The  early  results 
led  to  rather  stringent  requirements:  in  essence,  they 
required  the  fail-stop  property  [17]  or  something  very 
similar  to  it  [18].  Thus  they  did  not  have  much  practi¬ 
cal  application. 

More  recent  work  has  concentrated,  not  on  design¬ 
ing  protocols  that  are  guaranteed  to  be  composable, 
but  on  reducing  the  amount  of  work  that  is  required  to 
show  that  protocols  are  composable.  In  our  work  in  us¬ 
ing  the  NRL  Protocol  Analyzer  to  analyze  the  Internet 
Key  Exchange  protocol,  we  found  it  useful  to  take  each 
state  transition  that  required  an  input  message  and  de¬ 
termine  which  transitions  could  produce  that  output. 
This  information  was  stored  in  a  database,  and  only 
those  rules  that  have  a  chance  of  producing  that  out¬ 
put  are  consulted  when  the  reachability  of  an  output  is 
being  verified.  This  allowed  us  to  reduce  the  number 
of  state  transitions  that  had  to  be  tested  whenever  we 
had  to  determine  how  a  message  could  be  produced, 
thus  limiting  the  state  explosion  problem.  We  do  not 


make  any  claims  for  the  originality  of  this  idea  (indeed 
some  sort  of  rule  pre-verification  and  storage  is  nor¬ 
mally  done  by  rule-based  systems  that  must  process 
a  large  number  of  rules),  but  we  were  suprised  at  the 
dramatic  speedup  it  caused,  (at  least  threefold  for  the 
IKE  analysis  [29]).  This  is  a  technique  that  would  be 
useful  for  the  analysis  of  any  complex  protocol,  but 
which  was  particularly  helpful  for  the  analysis  of  suites 
of  protocols,  since  only  a  few  state  transitions  from  dif¬ 
ferent  protocols  had  the  potential  of  interacting  with 
each  other. 

Independently,  Thayer,  Herzog,  and  Guttman  used 
a  similar  insight  to  develop  a  technique  for  analyzing 
composition  properties  using  their  strand  space  model 
[49] .  Their  technique  consists  of  showing  that  a  certain 
set  of  terms  generated  by  the  first  protocol  can  never  be 
accepted  by  principals  executing  the  second  protocol. 
This  information  is  then  used  to  prove  the  full  result 
that  the  first  protocol  does  not  interfere  with  the  sec¬ 
ond.  The  techniques  used  for  choosing  the  set  of  terms 
and  for  using  them  in  the  proof  are  specific  to  the  pro¬ 
tocols  used  in  [14],  but  it  is  likely  that  they  could  be 
generalized  into  heuristics  that  could  be  applied  more 
widely.  We  think  that  it  is  likely  that  these  techniques 
will  continue  to  be  useful  as  they  are  further  refined. 

We  also  believe  that  the  last  word  has  not  been  writ¬ 
ten  on  designing  protocols  that  are  guaranteed  to  be 
composable,  or  are  at  least  easier  to  prove  composable. 
Recently  some  promising  work  has  been  done  on  de¬ 
signing  protocols  that  are  verifiable  by  model-checkers 
[24,  44].  A  model-checker  checks  that  a  protocol  is 
secure  by  simulating  its  interaction  with  an  intruder. 
Since  simulation  is  used,  only  a  finite  number  of  ex¬ 
ecutions  of  the  protocol  can  be  examined.  Thus  it  is 
helpful  to  know  if  there  is  some  finite  number  of  execu¬ 
tions  such  that  the  examination  of  this  finite  number 
is  enough  to  guarantee  security.  In  general,  the  answer 
to  this  is  no  [13,  18,  6],  but  it  is  still  possible,  as  is 
shown  by  the  work  of  Lowe  [24]  and  Stoller  [44] ,  to  put 
design  constraints  on  protocols  that  guarantee  them 
to  be  verifiable  through  examination  of  a  finite  num¬ 
ber  (and  manageable)  number  of  executions.  Moreover, 
the  constraints  involved  are  much  more  realistic  than 
the  fail-stop  constraint  used  in  the  early  composability 
results. 

We  believe  that  this  work  could  be  used  in  the  anal¬ 
ysis  of  composability  in  the  following  way.  Consider 
a  protocol  that  integrates  a  set  of  straight-line  sub¬ 
protocols  (where  a  “straight-line”  protocol  is  defined 
to  be  one  that  involves  no  if-then-elses  or  loops)  by 
proceeding  in  two  stages.  In  the  first  stage,  an  initia¬ 
tor  chooses  which  of  a  suite  of  straight-line  protocols  it 
will  execute.  In  the  next  stage  it  executes  the  subpro¬ 


tocol.  In  order  for  two  subprotocols  to  interact  harm¬ 
fully,  at  least  two  executions  of  the  protocol  must  have 
taken  place.  If  we  can  modify  Lowe’s  and/or  Stoller’s 
results  so  that  they  would  still  hold  in  such  an  environ¬ 
ment,  then  they  could  be  used  to  limit  the  complexity 
of  checking  for  an  interaction  by  limiting  the  size  of  the 
set  of  subprotocols  that  needs  to  be  checked  at  any  one 
time. 

4.6  Negotiation  of  Complex  Data  Structures 

Key  distribution  and  agreement  protocols  usually 
negotiate  agreement  upon  a  single  field:  the  key.  Most 
work  on  formal  analysis  of  cryptographic  protocols  has 
concentrated  on  this  problem.  But  once  more  structure 
is  introduced  into  the  data  to  be  agreed  upon,  new 
problems  of  maintaining  the  consistency  of  the  data 
emerge.  For  example,  Thayer,  Herzog,  and  Guttman 
[50]  recently  discovered  a  new  attack  on  the  Otway- 
Rees  protocol,  which  distributes  a  key  and  a  key  iden¬ 
tifier  together.  In  this  attack  the  principals  wound  up 
agreeing  on  the  same  key  identifier  but  not  the  same 
key.  Although  the  Otway- Rees  protocol  had  been  care¬ 
fully  studied  in  the  past,  this  possible  behavior  had  not 
been  uncovered  before. 

Many  of  the  newer  protocols  negotiate  agreement  on 
much  more  complex  structures  than  this.  As  we  saw 
earlier,  the  Internet  Key  Exchange  Protocol  negotiates 
agreement  on  a  complex  data  structure  that  not  only 
includes  multiple  fields,  but  is  also  open  ended.  SET 
goes  IKE  one  further  by  having  principals  agree  on  a 
data  structure  the  contents  of  whose  fields  are  gener¬ 
ated  by  different  members  of  a  three-party  protocol  as 
the  protocol  progresses,  so  that  we  are  dealing  with  a 
data  structure  that  evolves  as  the  protocol  completes. 
Moreover,  different  parts  of  the  structure  may  be  kept 
secret  from  different  principals,  so  it  is  possible  that  no 
one  principal  knows  the  contents  of  all  the  fields  in  the 
data  structure,  even  after  the  protocol  completes. 

In  spite  of  this  complexity,  we  found  the  tool  we 
were  using,  the  NRL  Protocol  Analyzer,  adequate  to 
this  task,  except  for  the  case  of  open-ended  data  struc¬ 
ture,  described  in  Section  4.1.  The  hard  part  was  un¬ 
derstanding  and  specifying  the  protocol  requirements 
that  needed  to  be  satisfied,  especially  for  SET.  We  were 
fortunate  to  have  the  NPATRL  requirements  language 
[48],  that  had  been  developed  specifically  to  specify 
complex  protocol  requirements  for  the  NRL  Protocol 
Analyzer.  However,  we  still  found  it  necessary  to  aug¬ 
ment  it  in  order  to  reason  about  agreement  on  data 
structures  with  possibly  unknown  or  not  yet  defined 
fields.  We  did  this  in  terms  of  specifying  requirements 
on  agreement  on  projections  of  the  entire  data  struc- 


ture.  This  was  not  difficult  to  do,  but  did  require  an 
enhancement  to  the  NPATRL  language. 

We  can  see  other  types  of  data  structures  emerg¬ 
ing  as  well.  Certificate  hierarchies  are  one  example. 
Since  any  protocol  that  manages  certificate  hierarchies 
must  deal  with  the  revocation  of  certificates  as  well, 
this  brings  up  the  problem  of  introducing  negation. 
There  is  also  a  growing  body  of  work  on  using  certifi¬ 
cates  to  implement  security  policies  (e.g.  Policymaker 

[2]).  Although  there  has  been  a  good  deal  of  research  in 
the  development  of  policy  definition  languages,  little  of 
this  work  has  concentrated  on  examining  their  interac¬ 
tion  with  the  protocols  that  implement  them.  It  is  still 
early  to  tell  if  there  are  any  problems  here  the  require 
special  attention,  but  the  area  bears  watching. 

4.7  Getting  it  into  the  Real  World 

Throughout  most  of  this  paper,  we  have  concen¬ 
trated  on  extending  the  limits  of  research.  But  we  also 
need  to  concentrate  on  getting  the  results  of  our  re¬ 
search  out  to  the  people  who  can  make  best  use  of  it: 
the  designers  and  evaluators  of  the  cryptographic  sys¬ 
tems  that  are  being  deployed  in  our  networks.  For  this 
we  want  not  to  concentrate  on  cutting-edge  research 
problems,  but  on  what  we  do  best  now,  and  what  is 
the  best  use  we  can  make  use  of  these  capabilities. 

I  think  that  few  would  argue  that  what  we  do  best 
now  is  the  analysis  of  straight-line  key  distribution  and 
authentication  protocols,  in  which  the  lowest  level  of 
abstraction  used  is  a  black-box  model  of  a  cryptosys¬ 
tem.  For  these  types  of  protocols  there  now  exist  be¬ 
lief  logic  tools  that  can  do  provide  a  totally  automated 
analysis  [3].  On  a  somewhat  deeper  level  there  are 
a  number  of  state-based  analysis  tools  that  can  do  a 
more  thorough  analysis  with  minimal  input  from  the 
user.  High-level  languages  like  CAPSL  [35]  also  make 
it  easy  to  specify  these  protocols  in  a  way  usable  by 
the  tools. 

We  have  noted,  of  course,  that  the  reality  is  often 
much  more  complex  than  the  simple  protocols  that 
these  tools  were  devised  to  analyze.  But  most  of  the 
complex  protocols  had  their  origins  in  the  simpler  jour¬ 
nal  level  protocols;  for  example  the  complex  Internet 
Key  Exchange  protocol  is  in  part  derived  from  the 
very  simple  Station  to  Station  protocol.  Nor  are  the 
“simple”  protocols  as  transparent  as  they  might  ap¬ 
pear  at  first  glance.  Lowe’s  analysis  of  the  Needham- 
Schroeder  public  key  protocol  and  Thayer,  Herzog,  and 
Guttman’s  analysis  of  the  Otway-Rees  protocol  show 
that  it  is  possible  for  possibly  harmful  properties  to 
go  undiscovered  for  years.  Thus,  it  is  important  to 
have  the  ability  to  recognize  and  fix  potential  problems 


up  front.  If  we  think  of  the  existing  tools  as  provid¬ 
ing  the  potential  for  animating  “back-of-the-envelope” 
sketches  of  protocols  so  that  they  can  be  thoroughly 
examined  before  the  effort  is  made  to  developed  them 
into  more  finished  products,  I  think  we  will  have  an 
idea  of  how  our  tools  as  they  exist  now  can  be  made 
immediately  useful  to  protocol  designers. 

5  Conclusion 

In  this  paper  we  have  given  a  brief  outline  of  the 
state  of  the  art  of  cryptographic  protocols  and  shown 
many  directions  in  which  it  could  be  extended.  Most 
conclusions  to  papers  include  suggestions  for  further 
research.  Since  this  paper  consists  of  nothing  but  sug¬ 
gestions  for  further  research,  we  will  forgo  that  here. 
However,  we  do  note  that  we  did  not  intend  our  list  of 
topics  to  be  exclusive.  Indeed,  we  imagine  that  there 
will  be  many  other  areas  that  come  to  light  as  research 
progresses. 
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